feat: add library variable set list and view commands - #697

Refs #346

What this adds

A new top-level octopus library-variable-set command (aliases library-variable-sets, lvs) with two read-only subcommands.

library-variable-set list — lists the variable sets in the space, sorted by name, with --filter/-q for substring matching. Script modules share the libraryvariablesets endpoint and are excluded (the existing sharedVariable.GetAllLibraryVariableSets helper already filters on ContentType == "Variables").

library-variable-set view [<name> | <id>] — this is the part aimed at the issue. It resolves the set, fetches its variables, and groups every value stored under the same variable name into one entry, with the unscoped value first because it is the fallback the scoped ones override. --filter/-q narrows to variables whose name contains a string; --web/-w opens the set in the browser. Prompts for the set in interactive mode, errors in --no-prompt.

This addresses both pain points named in the issue:

• "scoped and non-scoped versions show up as separate entries" — they are now one entry with several values.
• "switching between /libraryvariablesets/ and /variables/ doesn't make much sense" — one command does both requests and stitches the result together.

Scope IDs are resolved to display names via the variable set's ScopeValues, falling back to the raw ID rather than erroring, so one unresolvable scope value can't break the whole view (this differs deliberately from pkg/cmd/project/variables/shared.ToScopeValues, which returns an error).

Table output (-f table, the default) prints one row per stored value, with the variable name on every row:

NAME         VALUE            SCOPE                    ID
Slack.Token  ***              (unscoped)               Variables-4
Slack.Url    https://default  (unscoped)               Variables-1
Slack.Url    https://prod     Environment: Production  Variables-2
Slack.Url    https://test     Environment: Test        Variables-3

-f json emits the set's own fields plus Variables as an array of {Name, Values[]}, each value carrying Id, Value, IsSensitive, IsScoped, a Scope object using the API's own property names (Environment, Role, Machine, TenantTag, …) with resolved names, and a flat ScopeSummary string. -f basic prints a grouped text block. Sensitive values are masked as ***.

This also lights up the previously-unused annotations.IsLibrary group, so the root help now has a LIBRARY COMMANDS section.

Deliberately left out

• No create / update / delete, of sets or of variables. Editing a variable through /api/{space}/variables/variableset-… is a read-modify-write of the whole variable set with optimistic concurrency on Version; doing it safely (and prompting for scopes) is a much bigger surface than a first slice should carry, and it deserves its own design discussion — see the open question below.
• Script modules — filtered out of list, and view won't resolve one.
• Variable set templates (the tenant-facing variable templates on a set) — view reports only TemplateCount.
• No new selector in pkg/question/selectors — resolution lives in pkg/cmd/libraryvariableset/shared, mirroring pkg/cmd/channel/shared.ResolveChannel. Worth promoting if a second command needs it.

Follow-up surface, roughly in the order I'd do it: create/delete of a set (cheap, the SDK has Add/Update/DeleteByID); variable create/update/delete within a set, reusing pkg/cmd/project/variables/shared scope flags; script-module support; templates.

Test evidence

go build ./... — clean.

go test ./pkg/... — pass, exit 0, no failures. New tests:

• pkg/cmd/libraryvariableset/shared/shared_test.go — grouping (including case-insensitive names and unscoped-first ordering), scope ID→name resolution, fallback to the raw ID for unknown scope values, tolerance of a missing ScopeValues lookup, sensitive masking.
• pkg/cmd/libraryvariableset/list/list_test.go — table/json/basic, name filter, script modules excluded.
• pkg/cmd/libraryvariableset/view/view_test.go — required-in-automation-mode error, unknown-set error, interactive prompt, grouped table, basic, json.

Test support changes: NewLibraryVariableSet / NewVariableSetForLibraryVariableSet fixtures, and the LibraryVariables + Variables links added to testutil.NewRootResource() (they were missing, so the SDK couldn't build those service paths under test).

Decisions — settled on existing convention

• Command noun: library-variable-set (alias lvs). Every multi-word command in the CLI is a flat kebab-case noun — project-group, worker-pool, ephemeral-environment, build-information — and there is no namespace-parent command anywhere in NewCmdRoot. variable-set would be ambiguous with project variable sets and octopus project variable; a library parent would commit us to a namespace none of whose siblings (library certificate, library script-module, library step-template) exist yet. Abbreviated aliases have precedent: kubernetes carries k8s. If we later want a library parent we can add it and alias.
• JSON carries resolved names, not scope IDs. project variables list is the closest prior art: VariableAsJson embeds the SDK variable and shadows its ID-bearing Scope with a name-bearing VariableScopeValues, so consumers get names only. tenant variables list does the same (OwnerName, Environment as names). No ScopeIds field.
• No scope filters on view. The seven --*-scope flags in pkg/cmd/project/variables/shared exist on the write commands only; project variables list takes just --project and --git-ref. Read commands in this CLI filter on name, and -f json is the answer for anything more selective.
• The table repeats the variable name on every row, with an ID column. project variables list prints one row per variable with a bold NAME and a dimmed ID column, and no cell in any table in the CLI is blanked to imply "same as above". Blanking reads slightly better for a human, but it is a format nothing else in the CLI uses.

Open question — for a maintainer, not prior art

Should variable editing live in the CLI at all? This PR is read-only, which already solves the issue's stated problem (understanding a variable set), but the issue author links the "update a variable set variable" docs page, so they clearly want to write too.

The write path is a whole-variable-set read-modify-write with a Version for optimistic concurrency; a CLI that silently clobbers a concurrent edit would be worse than no CLI. It also needs sensitive-value handling — the server never returns them, so a naive round-trip would blank them.

My suggestion is a middle ground next: set-value for an existing variable identified by name + scope, a targeted read-modify-write with explicit conflict detection on Version, before attempting general create/delete. I'd like a call on whether we're comfortable with the CLI writing variable sets at all before building it.

🤖 Generated with Claude Code